Computer method and apparatus for securely managing data objects in a distributed context

ABSTRACT

In a network of intermittently-connected computers, a method and apparatus for maintaining and managing control over data objects authored, accessed, and altered by users in dynamic, distributed, and collaborative contexts. The invention method and apparatus attach to each data object an identification of a respective control policy. Each control policy comprises at least an indication of a subset of the users who may access the data object, an indication of the privileges granted to each subset of users able to access the data object, and an indication of a subset of users who may define or edit the control policy. The invention method and apparatus separate the management of the control policies of data objects from the creation and use of the data objects. The invention method and apparatus automate common policy changes, distribution of policy changes to the enforcement agents, and propagation of control policies to derivative works.

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.60/475,109, filed on Jun. 2, 2003, the entire teachings of which areincorporated herein by reference.

BACKGROUND OF THE INVENTION

The present invention relates to the field of usage rights enforcementand management for digitally encoded documents and data.

The encoding and distributing of audio, video, graphical, and writtenwork in digital formats has become a fundamental part of modernbusiness. However, the ease with which copies may be made that areidentical to the original and the speed of distribution enabled by theInternet have caused the owners of such works to adopt technologies thatassociate and enforce usage rights with digitally encoded data. Examplesof those interested in such technologies include: providers of music,movies, or other entertainment content; publishers of electronicnewspapers, magazines, or books; and corporations with confidential,proprietary, or otherwise sensitive information. Without loss ofgenerality and for ease of exposition, we will refer to all of thesekinds of digitally encoded works as data objects.

Many approaches exist to associate and enforce usage rights with dataobjects. One common approach is based on technologies that attempt toprevent the unauthorized copying of data objects from the physical mediacarrying the objects. U.S. Pat. No. 5,513,260 is an example of one suchcopy protection scheme.

Though copy-protection techniques are appropriate for some domains, thetypes of usage rights that they can enforce are too coarse grained to bea general solution. For example, the owner of a proprietary andconfidential document may wish to have one group of individuals be ableto only read a protected document and a different group be allowed toread and write it. Copy-prevention technologies are not powerful enoughto describe such usage policies.

More general-purpose approaches exist that protect the data objects sothat only authorized users can access and use the objects according to aset of rules specified for each class or group of authorized user. Thisapproach typically relies on encryption technology to guarantee thatonly authorized users have access to the actual data object. Inparticular, authorized users are given access to the secret key neededto decrypt the protected object and produce the actual data object. Theusage rights typically specify who is authorized to access the secretkey and what an authorized user can do with the decrypted data object.This basic approach includes the large body of work in digital rightsmanagement (DRM) and related rights management technologies. Though thisapproach does not prevent copying of the encrypted bits, it achieves thesame end result as copy protection since unauthorized users cannotaccess the protected data objects without the secret key.

To be effective, a rights management system must tightly couple theusage rights to the encrypted data objects so that the usage rightsalways appear with the associated object. This coupling should make itvery difficult and ideally impossible for someone, who is not the ownerof the object or otherwise authorized, to separate the data object fromits usage rights.

We can group attacks that attempt to separate a data object from itsusage rights into two categories. The first category comprises attackson the combination of the usage rights and encrypted data object.Replacing the usage rights of one file with the usage rights of anotheris an example of an attack in this category. The second categorycomprises attacks undertaken while the data object is decrypted andbeing used by an authorized user. The goal here is to obtain anunprotected copy of the decrypted data object by directly circumventingthe usage rights. To be effective, a rights management system mustcontain mechanisms that protect against both categories of attack.

The second category of attacks highlights the fact that the encrypteddata object must eventually be decrypted in order to be accessed by anauthorized user. A rights management system may either allow the user todecrypt the data object directly, or it may require the deployment anduse of rights-management-aware applications. In many commercialsituations, the owner of the protected data object may not want tobother the end user with an explicit encryption and decryption step ormay not trust the end user to abide by the usage rights. Thus, thepreferred method is to employ rights-management-aware applications thattransparently decrypt the data objects for authorized users and enforcethe usage rules attached to the objects. Rights-management-awareapplications act as trusted agents for the rights management system,enforcing the rules specified by the owners of the protected dataobjects. Media players that can play music files in encrypted formatsare examples of rights-management-aware applications.

The closeness of the coupling and the reliance on trusted applicationagents constitute the fundamental differences between rights managementsystems and technologies like encrypting file systems. In an encryptingfile system (e.g., Microsoft's EFS, U.S. Pat. No. 6,249,866), usagerights are associated only with the computer structure holding the dataobject (e.g., a file) and not with the data object itself. Sinceapplications are not aware of the usage rights enforced by an encryptingfile system, it is fairly simple for a user, who is authorized to accessthe object but not to change its usage rights, to save the data objectin a manner that does not propagate the rights. In particular, anauthorized user of a protected file in an encrypting file system needsonly to save the file to a directory outside the encrypting file systemto create an unencumbered copy of the protected file.

The use of rights-management-aware applications allows a rightsmanagement system to enforce a tight coupling between an encrypted dataobject and its associated usage rights. Some designers have chosen toimplement this tight coupling by storing the usage rights together withthe encrypted data object, producing a new data object that is oftenreferred to as a secure container (e.g., see U.S. Pat. No. 6,427,140).In this approach, usage rights are explicitly tied to a particular copyof the protected data object. This approach works well, for example, incommercial markets like online music where the owner of the data objectpublishes read-only content and simply wants to maintain control overthe usage and distribution of the content. We refer to such rightsmanagement systems as supporting publish-only distribution models.

A key characteristic of the publish-only distribution model is that theusage rights in the secure container are not expected to change overtime. Or if they do change, they change slowly, and the change affectsonly one end user at a time. To change the usage rights in thepublish-only distribution model, the owner must have access to thesecure container holding the usage rights. Access to the securecontainer would enable the rights management system to modify the usagerights stored in the container. If the secure container was notavailable, the owner can remove the end user's authorization to accessthe original secure container (e.g., by destroying the decryption keyfor this container) and re-issue a new secure container to the end userwith the same protected data object but new usage rights. This latterapproach requires the rights management system to notify the end user ofthe new secure container, and it requires that the rights managementsystem has a copy of the data object to put into the new securecontainer.

Though these requirements are not an imposition in a domain like onlinemusic, they are a serious impediment to dynamic environments, i.e., oneswhere the usage rights protecting data objects may change frequently andin possibly significant ways. These requirements are also a seriousimpediment to distributed environments, where multiple users may haveindividual copies of a protected data object on diverse computer devicesand storage media, some of which may not be online or otherwiseaccessible to the owner of the protected object. Clearly, it is notpossible in such environments for the rights management system to haveaccess to all of the copies of the protected object when the ownerwishes to make a change to the usage rights of that protected object. Itis also not desirable to re-issue a new protected data object to a groupof users, since the change in usage rights may affect only a few usersand should be unnoticed (transparent) to the rest. Furthermore, it maynot even be possible to re-issue the protected data object in adistributed environment where the owner controls the usage rights butdoes not have a copy of the latest version of the object.

In a truly collaborative environment, it's often difficult and sometimesimpossible to identify a single “publisher” of collaborative material.For corporate data, it is possible however to identify the “owner” ofcollaborative material produced for the purposes of a corporation'sbusiness. The owner is the company that employs the author or authors ofthe collaborative works. For collaborative environments then, there is aclear need to distinguish between those who produce sensitive materialand those that determine the usage rights of the same material.

Authentica has patented a partial solution to the enforcement andmanagement of usage rights for digital data objects in dynamic anddistributed environments (U.S. Pat. No. 6,449,721). This approach allowsthe owner of a digital data object to maintain control over the usagerights even after the protected objects have been distributed to endusers. In particular, the approach stores the usage rights of protectedobjects in a single, central location so that an owner of a protecteddata object can change the usage rights of that object without requiringsimultaneous access to any of the (possibly numerous) copies of the dataobject. Ideally, this approach allows multiple, distributed copies ofthe data object to exist while maintaining only a single, authoritativecopy of the object's usage rights. Having a single, authoritative copyof the object's usage rights simplifies management of the usage rights.

Authentica's approach creates a unique identifier for each segment ofprotected information. The Authentica key server maintains anassociation between unique segment identifiers, the usage rights forthose segments, and the encryption keys used to protect and access eachsegment. To access a protected segment, an end user must authenticate tothe server and provide the identifier of the protected segment he or shewishes to access. Assuming that the user is authorized to access theprotected segment, the server responds with a decryption key for thatsegment and the usage rights for that segment and user combination. Arights-management-aware application on the end-user's machine uses theserver's response to provide the end user with the owner-designatedlevel of access to the protected segment.

Though an approach like Authentica's allows the owners of protected dataobjects to control usage of distributed information and dynamicallychange that usage information without the need to collect orredistribute the protected data objects, it is not a complete solutionto the problems associated with the enforcement and management of usagerights in collaborative environments. In particular, a solution forcollaborative environments needs to focus on protecting the products ofcollaboration in a manner that fits naturally into existingcollaborative models. For example, in commercial enterprises,collaboration often produces multiple documents all protected by thesame usage rights, and thus a truly collaborative solution should allowfor the easy grouping of multiple documents under a single set of usagerights. In addition, it is also often expected that derivative workscreated during collaboration would also be protected by the usage rightsof the collaboration and that changes to these rights would coincidewith existing processes for moving a work into a new collaborativesetting. Finally, all of the current rights management systems,especially those focused on publish-only distribution models, tootightly control the creation, modification, and distribution ofprotected documents to be appropriate for protecting the data objectscomprising collaborative interactions. An appropriate solution shouldclearly distinguish between the rights held by “authors” and those heldby “owners.”

SUMMARY OF THE INVENTION

Various technologies and inventions in this field, including models ofdiscretionary, mandatory, or role-based access control, and DRM (DigitalRights Management) related technologies have addressed one or another ofthe requirements mentioned above. The embodiments of the presentinvention, however, offer a unique approach that addresses all of thenecessary features for a rights management system targeting dynamic,distributed, collaborative contexts.

Aspects of the invention include a method and a system for maintainingand managing control over data objects authored, accessed, and alteredby users in dynamic, distributed, and collaborative contexts.

A data object is any audio, graphical, video, or written work encoded indigital form and encapsulated in a computer structure, such as a file,message, or shared memory object, that a software program can access andmanipulate.

A distributed and collaborative context is one in which groups of one ormore users work individually or collaboratively on collections of one ormore data objects on a network of computers with at least intermittentconnectivity to achieve some common purpose. In the present invention,we refer to this common purpose as a business process.

Within a business process, there can be classes of users with differentsets of rights and responsibilities. In the present invention, we referto these classes as roles.

The present invention considers a context to be dynamic if properties ofthe system can change during the lifetime of a business process. Forexample, the system might allow the set of users belonging to a role tochange during a business process, or it might allow the type of controlimposed on a data object to change. The invention separates thepublication and modification of protected data objects from theownership and manipulation of the policies controlling the usage ofthose data objects.

Control over a data object is specified by a set of rules describing howsoftware programs run by a computer user in a particular role may accessand manipulate the object. In the present invention, we refer to theserules as usage rights.

Control policies are signed assertions that describe the conditionsunder which usage rights are authorized. A control policy comprises atleast a list of users who may access the data object, the privileges ofthose users with access, and an additional list of users who may defineor edit the control policy. Policies in the present invention may alsodefine supplemental properties that apply to the objects under itscontrol, to assure authenticity, integrity, and confidentiality of thoseobjects.

As stated in the previous paragraph, the term ‘control’ as used in thepresent invention typically implies protection against access byunauthorized users and their applications.

A further objective of the present invention is to provide a system andmethod for obtaining visibility into a business process. Such visibilitymay be achieved without committing to the risks of securing data objectsby encrypting or otherwise changing the actual digital representation oftheir data objects. When control does not include protection, weobviously cannot ensure that we maintain control against maliciousadversaries, i.e. ones that manipulate the protected data objectsoutside of our protected environment. However, this level of control isstill desirable in business situations where an enterprise might wantvisibility into a business process while their data objects remain inplain text.

A further objective of the present invention is to provide a method andsystem for storing control policies on one or more central servers.

A further objective of the present invention is to provide a method andsystem for editing control policies, based on an indication of the usersthat may edit the control policies and the types of changes that thoseusers can perform. Changes to a control policy would be enacted on theserver storing that control policy.

A further objective of the present invention is to provide a method andsystem for temporarily changing one or more control policies and thenreverting back automatically to the original settings at some point inthe future.

A further objective of the present invention is to provide a method andsystem for having one or more preset temporary changes that can beenacted by the click of one button and then rolled back on the click ofanother button.

A further objective of the present invention is to provide a method andsystem for attaching to each data object an identification of one (i.e.,a respective) control policy. In the present invention, we refer to thecontrol policy whose identification is attached to a data object as thecontrol policy protecting that data object. We also refer to such a dataobject as a protected data object.

A further objective of the present invention is to allow multiple dataobjects to reference the same control policy.

A further objective of the present invention is to provide a method andsystem wherein the identification of a control policy specifies theserver in whose name space the actual control policy identifier isdefined. In the preferred embodiment, the policy reference attached to adata object comprises a server URL and a numerical value known to thatserver.

A further objective of the present invention is to provide a method andsystem for checking by a client connected possibly intermittently to apolicy server that a user attempting to create, access, or alter a dataobject protected by a control policy has the right to perform thataction on that data object. If the user has the right, the client allowsthe requested action to proceed. If the user does not have the right,the client responds with an appropriate error message. In other words,the protection provided by the business process approach does not justprotect proprietary, confidential, or otherwise sensitive data objectswhile they're stored on disk or transmitted over a communication link,but it also protects them while they are operated on by the softwareapplications of authorized users and during inter-applicationcommunication (e.g., clipboard operations in the Microsoft Windowsoperating system).

A further objective of the present invention is to provide a method andsystem with control policies that may contain conditions that specifydevice, location, time-of-access, or network connectivity constraints.

A further objective of the present invention is to provide a method andsystem wherein users authorized to edit a control policy can change thatpolicy without physical or electronic access to all data objectsprotected by the policy.

A further objective of the present invention is to provide a method andsystem allowing the only authoritative copy (or copies) of a protecteddata object to be located on computing machines or media of userswithout the rights to change the control policy protecting the dataobject.

In one embodiment of the invention, there is no notion of registering aprotected data object with the policy server before distributing it toother users. This is a key aspect of the system required to supportcollaborative work that involves creation and modification of dataobjects on machines of authorized users that may be off-line.

A further objective of the present invention is to provide a method andsystem for allowing authorized users to create new protected dataobjects even when the client that they are working on has lostconnectivity with the server of the specified control policy. Authorizedusers in this circumstance are those users that have the right to createdata objects under the control policy. In the preferred embodiment, theuser must have had some recent access to the policy server, where“recent” means within the cache timeout period as specified for thatpolicy.

A further objective of the present invention is to provide a method andsystem for two or more authorized users to view protected data objectsand work collaboratively on new and existing protected data objects evenwhen one or more of these users' clients may have lost connectivity withthe server (or servers) of the control policies protecting thecollaborative data objects. The protected data objects may never havebeen viewed while connected to the server (or servers). The shared dataobjects may be new, that is, created while the users did not haveconnectivity with the server.

A further objective of the present invention is to provide a method andsystem in which the storage of the policy server scales in proportion tothe number of control policies defined. The storage should not scale inproportion to the number of unique protected data objects nor with thenumber of copies of these protected data objects.

A further objective of the present invention is to provide a method andsystem for grouping control policies into business processes.

A further objective of the present invention is to provide a method andsystem for constructing a control policy by identifying one or moreroles involved in that control policy. Each role comprises a respectiveset of usage rights and a list of users.

A further objective of the present invention is to provide a method andsystem for aggregating the usage rights of a user appearing in multipleroles contained in a single control policy.

A further objective of the present invention is to provide a method andsystem for differentiating between users with the privilege toadminister (create, edit, and delete) business processes and theirencompassing control policies from those users with the privilege tomodify only the list of users in one or more roles of a control policy.

A further objective of the present invention is to provide a method andsystem in which the identification of a control policy on a data objectcan change. This change might cause the data object to be no longermanaged by the system.

A further objective of the present invention is to provide a method andsystem allowing users with appropriate usage rights to change thecontrol policy identifications on data objects. A user may be grantedthe right to unprotect data objects by changing the objects controlpolicy identifier to “unmanaged” or equivalent status.

A further objective of the present invention is to provide a method andsystem with control policies that further define a list of users who maytransfer data objects out of the control policy and a separate list ofusers who may assign the policy to data objects. Both of these actionsinvolve changing the control policy identifier attached to a dataobject. There may be times when these lists contain no users.

A further objective of the present invention is to provide a method andsystem for automating the transfer of data objects between controlpolicies for those users with the privilege to do the transfer andassign manually. The preferred embodiment of this aspect involvesintegrating a tool into the software component of an existing electronicbusiness process.

A further objective of the present invention is to provide a method andsystem for allowing the administrators of business processes todetermine the events that cause the automatic transfer of data objectsbetween control policies.

A further objective of the present invention is to provide a method andsystem for organizing business processes in a hierarchical manner. Sucha hierarchy may be used to limit the scope of transfers of data objectsbetween control policies. It may also be used to define control policiesor other properties that are common to several business processes in asingle location.

A further objective of the present invention is to provide a method andsystem (e.g., graphical user interface) for displaying and changing thecontrol policy of a protected data object. In one embodiment this isimplemented as a drop-down window located in the title bar of the windowdisplaying the data object. This drop-down window is referred to as thedroplet control. When a user clicks on the droplet control, a window mayopen up with several policies and options for selection by the user.

A further objective of the present invention is to provide a method andsystem for displaying the list of possible control policies that a usercan transfer the current data object to when the user activates thedroplet control.

A further objective of the present invention is to provide a method andsystem for changing a data object's control policy when a user selects anew control policy in the activated droplet control window of the dataobject.

A further objective of the present invention is to provide a method andsystem for illustrating the hierarchy of control policies withinbusiness processes within an activated droplet control window.

A further objective of the present invention is to provide a method andsystem for encrypting data objects with a content encryption key (CEK),which is then encrypted with a key encryption key (KEK) of the controlpolicy associated with the data object.

A further objective of the present invention is to provide a method andsystem for indicating whether the data objects protected by a controlpolicy should be treated as ephemeral or permanent objects. An ephemeraldata object is accessible until some designated future time; after thattime, the object becomes inaccessible and unrecoverable. A permanentdata object is always accessible or recoverable when presented to therights management system or its agents.

A further objective of the present invention is to provide a method andsystem for forcing all data objects protected by a control policy tobecome inaccessible and unrecoverable before the designated future time.The business process's administrator can permanently revoke accessearlier than planned.

A further objective of the present invention is to provide a method andsystem for recording the control policy identifier in a data structurestored with the (possibly encrypted) bits of the protected data object.In the preferred embodiment, we refer to this data structure as theControl Policy Tag (CPT).

A further objective of the present invention is to provide a method andsystem for attaching the CPT to the beginning or end of the protecteddata object.

A further objective of the present invention is to provide a method andsystem for constructing the CPT of a protected data object on either aclient or a server machine.

A further objective of the present invention is to provide a method andsystem for storing the CEK safely in the CPT. The client can accessprotected data objects off-line with only cached policy and key (KEK)information because the CPT contains the CEK.

A further objective of the present invention is to provide a method andsystem for automatically replacing an expired CPT on a protected dataobject. Expiration of a CPT may occur because the CPT format has changedor the control policy KEK for the CPT has expired (i.e., gone beyond itsvalidity period).

A further objective of the present invention is to provide a method andsystem where the trustworthy clients of the rights management system donot need code to interpret old CPT formats.

A further objective of the present invention is to provide a method andsystem for indicating that a control policy protects data objects thatare read-only or stored on read-only computer media.

A further objective of the present invention is to provide a method andsystem for informing an unauthorized user of the system protecting thedata object accessed. The preferred embodiment includes a text messagein the CPT.

A further objective of the present invention is to provide a method andsystem for protecting the integrity of the CPT against tampering. Thepreferred embodiment uses a secure hash over the CPT fields.

A further objective of the present invention is to provide a method andsystem for protecting the confidentiality of a data object's CEK whilestored in the CPT. The preferred embodiment encrypts the CEK with thecontrol policy's KEK. The encrypted CEK is protected against knownplaintext attacks (i.e. attacks based on the knowledge of identicalpieces of two similar documents) by using random seed values andchanging the CEK whenever the data object is changed.

A further objective of the present invention is to provide a method andsystem for protecting the server and client communication againstnetwork-based attacks. The preferred embodiment uses a HypertextTransfer Protocol over Secure Socket Layer (HTTPS) connection forcommunications between the client and server.

A further objective of the present invention is to provide a method andsystem for enabling an audit or forensic analysis of a business processbased on activities granted and denied within one or more of the controlpolicies of that business process.

A further objective of the present invention is to provide a method andsystem for identifying the data objects in an activity log based onunique document identifiers maintained in the CPT.

A further objective of the present invention is to provide a method andsystem for allowing the client to access the server at user login timeto obtain and cache the control policies in which the user is mentioned.This feature addresses issues arising in collaborative and distributedenvironments, including intermittent connectivity, off-line usage ofprotected data objects, and off-line collaboration with others mentionedin the control policy.

A further objective of the present invention is to provide a method andsystem for varying the polling frequency at which clients verify cachedpolicies with the server. The frequency may be set so that the clientmust always verify the cache policy before permitting access.

A further objective of the present invention is to provide a method andsystem for having clients verify and refresh cached policies whennetwork access is restored.

A further objective of the present invention is to provide a method andsystem for the server to prompt clients to refresh their cachedpolicies.

A further objective of the present invention is to provide a method andsystem for specifying the expiration time of a cached control policy.

A further objective of the present invention is to provide a method andsystem for specifying the validity period of the KEK of a controlpolicy.

A further objective of the present invention is to provide a method andsystem for allowing the server to supply a client with a limited historyof KEKs for a control policy. The use of an expired policy KEK in aprotected data object does not force the client to have to contact theserver before accessing the object. Even though a user never accesses aprotected data object while online, as long as his or her off-lineaccess occurs within the cache timeout period of the control policy ofthe data object, the user will not be denied access due to anout-of-date KEK.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescription of preferred embodiments of the invention, as illustrated inthe accompanying drawings in which like reference characters refer tothe same parts throughout the different views. The drawings are notnecessarily to scale, emphasis instead being placed upon illustratingthe principles of the invention.

FIG. 1 is a schematic diagram of an organization structure for rightsmanagement policies;

FIGS. 2-5 are illustrations of various applications of businessprocesses and control policies;

FIG. 6 is an architectural block diagram of main components of oneembodiment of the invention;

FIG. 7 is a flow diagram describing logic of policy administration;

FIG. 8 is a schematic illustration of a control policy tag;

FIG. 9 is a flow diagram of accessing a protected data object;

FIG. 10 is an architectural block diagram of the client agent in anotherembodiment of the present invention;

FIG. 11 is a flow diagram of client handler processing;

FIG. 12 is an illustration of key encryption, key distribution andexpiry;

FIG. 13 is a second flow diagram of accessing a protected data object;

FIG. 14 is a third flow diagram of accessing a protected data object;

FIG. 15 is an illustration of control policy display;

FIG. 16 is a flow diagram of policy transfer logic;

FIG. 17 is a flow diagram of off-line collaboration between two users.

DETAILED DESCRIPTION OF THE INVENTION

A description of preferred embodiments of the invention follows.

The present invention starts with centralized management of usage rightsorganized in a structure that mirrors the important processes of thebusiness. FIG. 1 illustrates the organizing structure 10 for policiesemployed in one embodiment of the present invention. A business process12 represents progressively continuing procedures based on controlledphases or activities that are systematically directed at achievingspecific business results. Business processes 12 within the hierarchicalorganizing structure 10 act as containers that hold one or more controlpolicies 14. A control policy 14 specifies usage rules that govern howthe protected data objects may be used and by whom. Policies typicallyrepresent the phases or activities within a business process and areflexible enough to support data classifications (e.g. companyconfidential, executive only, etc.). Each protected data object(illustrated as a document) is associated with and under the control ofa single control policy 14 within a business process 12. Each controlpolicy 14 specifies one or more roles 16. A role 16 describes the set ofusers (or groups) and their privileges on the data managed by a policy14.

Using the organizing structure 10 in FIG. 1, the following embodiment ofthe present invention will allow an organization to retain control ofusage and flow of its data objects in a manner that separates rightsmanagement actions from physical access to the copies of data objects.For example, assume that we are given a set of data objects, all ofwhich are protected by a single control policy; note that this set maycontain only a single data object. The invention and its preferredembodiments guarantee that changes to the control policy will bepropagated to end users and ultimately experienced by those users whenthey next access the data objects protected by that changed policy. Thisguarantee holds even though access by the owner of the protected dataobjects to any or all copies of those objects may be impractical orimpossible at the time of the change.

The preferred embodiments will illustrate how the present inventionsupports the transparent use of protected data objects in a dynamic,distributed, and collaborative environment, where multiple users aremodifying individual copies of protected data objects on diversecomputer devices and storage media, some of which may not be online orotherwise accessible to the owner of the protected data objects. Thediscussion will clearly show that the invention supports the distinctionbetween an information author and owner. It will also illustrate thatthe invention includes protections against adversaries that would try toattack the association between policies and data objects.

As an example of a dynamic, distributed, collaborative environment wherewe need to protect data objects while simultaneously providing theability to create, modify, and distribute these protected data objectswithin the constrains of a policy model, consider a company that wishesto control and protect data objects in compliance with NASD 2711, aregulation that requires a clear and auditable separation of informationbetween the bankers and research analysts in investment banks. FIGS. 2-5enumerate hypothetical steps in such a dynamic, distributed, andcollaborative process.

The “NASD 2711” business process 150 comprises three control policies14: “Background Research” 152 (FIG. 2); “Industry Review” 154 (FIGS. 3and 4); and “Publish” 156 (FIG. 5). The “VP Compliance” owns thebusiness process and administers all aspects of it. For the “BackgroundResearch” policy 152 in FIG. 2, she creates two roles: “Analyst” and“Director”. Each person listed in the “Analyst” role is able to create,read, and write reports within the “Background Research” policy. Eachperson listed in the “Director” role can read (but not write) the reportand transfer a copy of such reports to the “Industry Review” policy 154.

The example illustrated in FIG. 2 describes the creation of an analystreport for “Big Motor Co.”, which is protected and controlled by the“NASD 2711” business process 150. As the figure illustrates, analystscan draft and collaborate on reports (a data object) in this policy 152,and when they have completed a report, they can forward it to the“Director of Research”, who is a member of the “Director” role, forreview and ultimately transfer to compliance. Individuals not listed inone of the roles under the “Background Research” policy 152 are unableto access the reports protected by this policy.

FIG. 3 describes the first part of the dynamic “Industry Review” piece154 of this business process 150. “Industry Review” comprises a policywith three roles: the “Director” role can read protected data objects inthis policy 154 and transfer data objects into the policy 154; the“Compliance” role can read the protected data objects, transfer copiesof data objects to the “Publish” policy 156 (FIG. 5), and administermembership in the “External Reviewer” role; and the “External Reviewer”role can edit the protected data objects. When the “VP Compliance”, whois a member of the “Compliance” role, receives a protected data objectfrom the “Director of Research”, who is a member of the “Director” roleof the “Industry Review” policy 154, the “VP Compliance” edits themembership of the “External Reviewer” role to allow the “BMCo CFO” andthe “Automotive I-Banker” to review and edit the protected analystreport. When the members of the “External Reviewer” role are done withtheir collaborative interaction, they will send the updated data objectback to the “VP Compliance”. The “VP Compliance” can now remove the“BMCo CFO” and the “Automotive I-Banker” from the membership of the“External Reviewer” role (and thus from the “Industry Review” policy154) so that they are no longer able to view reports (subject dataobject) protected under the “Industry Review” policy, as illustrated inFIG. 4. Such removal illustrates one aspect of the dynamic nature of thepresent invention.

FIG. 5 completes the progression of the analyst report through thephases of a Big Motor Co. analyst review constrained by the “NASD 2711”business process 150. FIG. 5 illustrates the three roles within the“Publish” policy 156, all of which can read but not write the protecteddata objects. In addition, the “Compliance” role can transfer dataobjects into the policy 156, and the “Director” role can administermembership in the “Reader” role. When the “VP Compliance” in the“Compliance” role transfers a copy of an analyst's report to the“Publish” policy 156, the “Director of Research” in the “Director” roleadds the necessary parties (e.g., the sales group and the BMCo CFO) tothe “Reader” role and makes the protected analyst report available tothe outside world.

The block diagram in FIG. 6 illustrates the main architecturalcomponents of an embodiment of the present invention and the primaryinteractions between these architectural components. A user 20 uses arights-management-aware application 21 to operate on a protected dataobject 32. The protected data object 32 comprises an encrypted dataobject 22 and a tag 23. In some embodiments, the data object 32 may notbe encrypted.

The reference monitor 24 in the client agent 26 intercepts operationrequests on the data of the protected data object 32 by therights-management-aware application 21. This monitor uses the tag 23 onthe protected data object 32 to obtain the usage rights in the policyprotecting this data object 22 for the user 20. The client agent 26 mayhave to communicate with the policy manager 27 on the policy server 29to obtain the details of the control policy identified by the tag 23.Assuming the user 20 has the right to perform the requested operation,the crypto engine 25 in the client agent 26 will perform the appropriateencryption operation for the requested operation on the data object 22.The encryption key required to perform this operation was originallyobtained from the key manager 28 on the policy server 29 as part ofcontrol policy request and reply actions.

The control policies stored on the policy server 29 may be created andedited by an appropriately authorized user 30 using a policyadministration application 31, which interacts with the policy manager27 on the policy server 29.

A particular embodiment may use multiple policy servers. Multipleservers may be used for the purpose of improved reliability or loadbalancing.

In a particular embodiment, the client agent 26 may have onlyintermittent connectivity with the policy server 29. Though theinvention supports the propagation of modified usage rights to thecopies of the effected data objects in a timely manner, the definitionof “timely” is set by the users 30 authorized to manage policies. Forexample, in some commercial situations, timely might mean that allaccesses to a data object after modification of its usage rights wouldbe governed by the new rights. In other situations where the commercialenvironment calls for limited “off-line” access to protected dataobjects, timely might mean that the usage rights are updated once thelocal agent for the rights management system comes back online.

Rights-Management-Aware Applications

The client application 21 in FIG. 6 is described as arights-management-aware application that cooperates with the clientagent 26 of the rights management system to enforce the policies storedon the policy server 29. There exist numerous methods for creating sucha rights-management-aware application. We might code the application 21to interact directly with the client agent 26. Alternatively, we mightcode an application 21 to load and use a set of rights managementlibraries with standard interfaces. We would then implement a version ofthese rights management libraries that would manage all interactionswith the client agent 26. Finally, the system on which the application21 runs might inject the client agent 26 into applications to createrights-management-aware applications, as described in U.S. patentapplication Ser. No. 10/194,655, filed on Jul. 11, 2002 by Bala andSmith, entitled “METHOD FOR PROTECTING DIGITAL CONTENT FROM UNAUTHORIZEDUSE BY AUTOMATICALLY AND DYNAMICALLY INTEGRATING A CONTENT-PROTECTIONAGENT” herein incorporated by reference.

In general, client-centric processing based on reference monitoring, asillustrated in FIG. 6, enables applications to become trusted agents ofthe rights management system and thus provide for local enforcement ofthe specified usage rights, even when the client machines aredisconnected from the rest of the rights management system. Embodimentsemploying dynamic injection enable existing as well as new applicationsto become immediate participants in the rights management system.

Policies and Policy Administration

In the embodiment explained below, a control policy 14 comprises atleast a list of the users authorized to access the data objectsprotected by that policy, a digest of the privileges granted to eachuser in the authorization list, a current Key Encryption Key (KEK), anda unique identifier (i.e., the Policy ID used in tags 23). Controlpolicies 14 may also contain conditions on those privileges; theseconditions may specify additional device, location, time-of-access, ornetwork-connectivity constraints.

The present invention differentiates between the set of users 20authorized to access data objects protected by a policy (mentionedabove) and the set of users 30 to administer (i.e. create, edit, anddelete) control policies and the encompassing business processes. Noticethat a user might be a member of both sets of users 20, 30.

To better address business process needs of enterprises, the preferredembodiment supports three explicit types of administrative users:information technology (IT) administrators; business process owners; andbusiness role administrators. IT administrators are those users thathave administrative access to the policy server 29 in FIG. 6. Their taskis to maintain the computing infrastructure required by the policyserver; the IT administrators are not needed to perform thebusiness-related administrative aspects of policy management. A businessprocess owner is a user with the right to administer a specifiedbusiness process. A business process owner may edit all aspects of thecontrol policies 14 within the owned business process, but he or shecannot modify other business processes (unless the user is also thebusiness process owner of those other business processes as well). Abusiness role administrator is a user that may modify the user listswithin the roles of a specified control policy 14. A business roleadministrator has a subset of the privileges granted to the businessprocess owner of the business process in which the business roleadministrator is named.

To facilitate further categorization of an enterprise's businessprocesses and directly reflect the hierarchical nature of businessprocess management, one preferred embodiment supports the organizing ofdefined business processes in a hierarchical manner. For example,consider a collection of business processes that are organized as atree. The business process at the root of the tree represents thetopmost context, and the business processes at the leaves of the treeare the individual components of the business process at the root.Additional interior tree nodes may be used to represent major categorieswithin the overall business process.

Such a hierarchy organized as a tree may be used to indicate the user orusers that are able to administer all of the business processes within asubtree of the hierarchy. Similarly, the indicated users might be ableto administer only the roles within that subtree.

FIG. 7 describes the logic of the policy administration application 31in FIG. 6. The process begins in step 40 with a user starting the policyadministration application 31 and connecting to a policy server 29. Inone embodiment, the policy administration application 31 is a J2EE webapplication. At step 41, the system verifies that the user is anauthorized administrator, identifies the type of administrator that theuser is, and determines the types of operations that the user canperform on the policy database. If the user is not authorized to performany actions or even view the database, an error message is displayed inStep 42. Step 43 presents a view of the business processes, theircontrol policies, and associated roles that the authorized user canadminister; the view depends upon the rights of the authorized user.Step 43 then waits for the user to select an action that modifies thedatabase of business processes.

An authorized user may choose to create or edit a business process,control policy 14, or role list, as illustrated in step 44. All changesperformed by the user are logged and committed in step 46. The changesare then displayed to the user in Step 43.

By logging the changes, the system may allow authorized users to undo anearlier change to the database on the policy server 29. In particular,Step 43 also allows the user to rollback a set of committed changes, asillustrated in step 45. This action is also logged and committed in step46. Steps 43 through 46 are repeated until the user exits the policyadministration application 31. All of these steps can occur without anyaccess to or knowledge of the exact data objects protected by thechanged business processes and policies on the policy server 29.

Security Knob

One preferred embodiment of the invention uses the rollback featurementioned above to implement a one-click security setting that can beenabled or disabled in a dynamic manner. We colloquially call theone-click security setting the security knob.

In the simplest case, consider a business process with two securityalert states: normal and lock-down. “Normal” is the default securitystate; the enterprise proceeds without any special considerations beyondthe policies enforced in the normal day-to-day workflow of this businessprocess. The security officers and business process owners have togetheralso defined a set of changes to this business process that should gointo effect whenever the business process is “under attack” or otherwisevulnerable (e.g., vulnerable to an identified and determined adversary,or vulnerable to potential violations of a governmental regulationduring some critical time period). When applied to the appropriatepieces of the business process, these set of changes comprise the“lock-down” security state.

A key aspect of this feature is that an enterprise or business processowner may want to enter this “lock-down” security state quickly and onlyfor a temporary time period. Once the threat or vulnerability haspassed, the system should revert to the policy characteristics definedfor the “normal” security state. It would be too slow, error-prone, andtedious to edit each of the pieces of a business process every time theenterprise or business process owner wanted to enter or exit the“lock-down” security state.

To implement this capability, one embodiment would create a set of logevents that would automatically be applied when the security knob wasset to a pre-defined setting. The log events for the “lock-down”security state described above could be captured by simply having theauthorized administrator perform the changes to the current businessprocess (i.e. “normal” security state), having the system log and storethose changes under the appropriate security setting identifier (i.e.,“lock-down”), and not having those changes actually applied to thedatabase at the time of definition. The log events for the transitionfrom “lock-down” to “normal” are simply those used to revert from the“lock-down” change.

To keep the security setting coherent, the system would ask the user ifhe or she also wanted to change, for example, the “lock-down” securitystate while the authorized user was making changes to the businessprocess under the “normal” security state.

Those of ordinary skill in the art should recognize the methods ofextending this two-setting security knob example and implementation toone that implements an n-setting security knob, for any specific ngreater than 2.

Policy Deletion

Since the system does not have access to all of the data objects 32protected by a control policy 14 when that policy is modified, we mustbe careful when “deleting” a control policy. First, we cannot reuse acontrol policy identifier from a “deleted” control policy for a newpolicy, since any data object 32 protected by the “deleted” policy wouldthen appear to be part of the new control policy. We might also wantsome privileged user to be able to recover data objects from “deleted”control policies.

In the preferred embodiment, we use a globally unique identifier (GUID)as the identifier on a control policy 14, ensuring that no two controlpolicies 14 ever get the same identifier. When an authorizedadministrative user deletes a control policy, the system removes thecontrol policy from the system (possibly logging the action and thedeleted information) so that data objects protected by the “deleted”control policy will appear as data objects that users are not authorizedto access. Recovering a protected data object is handled through the“disaster recovery” mechanism described later.

Encryption and the Control Policy Tag (CPT)

To ensure continuous protection of and control over a data object 22, apreferred embodiment of the current invention encrypts the data object22 when it is not being accessed by rights-management-aware application.To each encrypted data object 22, the system attaches a Control PolicyTag (CPT). FIG. 8 is an abstract representation of the control policytag 23 of the protected data object 32 in FIG. 6. The CPT contains thecontent encryption key (CEK) used to encrypt the data object 22. (Wedescribe all of the fields of the CPT below.) The CPT is also themechanism by which policies in the rights management system areassociated with data objects. The combination of an encrypted (orencryptable) data object 22 and its CPT is called a protected dataobject 32.

For each data object 22, the rights management system generates apseudo-random number that it uses as a symmetric key for encrypting anddecrypting the data object 22. This process effectively produces aunique CEK for each data object. The control policy tag 23 in FIG. 8 isa data structure with fields that provide identity information,encryption information, and integrity information. Though the fields mayappear in any order, a client agent 26 must always be able to find andinterpret the CPT version 51 and length 52 fields.

The version field 51 identifies the version of the CPT structure beingused. This field allows the system designers to change the format orcontents of the CPT in the future and yet still be able to accesscontent protected by old as well as new CPT structures (see FIG. 14 andits associated explanation below).

The version field 51 may begin with a “magic number” that contentfiltering applications can use to identify the data object 32 as oneencrypted and protected under the current invention. This “magic number”could, for example, be used by anti-virus scanning applications to knowthat the protected data object 32 is encrypted (and presumably free ofviruses due to a scan before encryption).

The length field 52 specifies the size of the CPT in bytes.

The text message field 53 is an optional field that explains to anunauthorized user (or users executing programs not under control of therights management system) that the attached data object 32 is protectedand where to go to get more information. This field is optional; somedeployments may choose greater secrecy (no information provided tounauthorized users) over ease-of-use concerns (informing users how theycan become part of the rights management system).

The control policy id field 54 identifies the control policy 14 thatprotects the attached data object. This field contains a globally uniqueidentifier (GUID). The control policy id field 54 may also specify(e.g., via a URL) the policy server 29 in whose name space the GUID isknown.

The object id field 55 is another optional field; it specifies a uniqueidentifier for each data object 22.

Each protected data object 32 is encrypted with a secret key, called theContent Encryption Key (CEK), and this key is stored in at least twoplaces in the CPT structure 23, labeled Encrypted CEK 56 and 57. One ofthese two fields 56, 57 contains the CEK encrypted with the policyserver's KEK. The other field contains the CEK encrypted with the KeyEncryption Key (KEK) of the policy identified in the control policy idfield 54. The KEKs may be either symmetric or asymmetric keys. For therest of the description of the preferred embodiment, we will assume thata KEK comprises a public/private key pair.

Another embodiment may include additional KEK fields that supportrole-based KEKs. In this manner, an administrator could specify uniquekey properties (e.g., shorter off-line access) for certain roles.

Since an embodiment of the present invention may use one or moredifferent content encryption algorithms, the encryption algorithm idfield 58 identifies the actual algorithm and other definable properties(e.g., key length) used to encrypt the data object with the CEK.

The final field, the integrity check field 59, is used to ensure that noone has tampered with the fields in the CPT 23. It may contain, forexample, a secure hash of the entire CPT.

If the data object is tagged but not encrypted, the two encrypted CEKfields 56 and 57 and the encryption algorithm id field 58 are zeroed.

Control policies 14 are considered an integral part of a protected dataobject 32, accompanying the data object even as it moves among computersand their internal structures (e.g., file systems and memory buffers).The CPT, which references the governing control policy through thecontrol policy id field 54 and contains the CEK secured by the controlpolicy's KEK, is propagated with the encrypted data object 22 untilexplicitly removed by an authorized user through an embodiment of therights management system of the present invention.

An explicit decision of the present invention is to allow multiple dataobjects 32 to refer to and be protected by a single control policy 14.The CPT structure described above clearly supports this decision. Theembodiment also emphasizes the fact that the value in the control policyid field 54 of the CPT does not uniquely identify a document (as aunique document identifier would do).

The policy server 29 of FIG. 6 stores only the details of controlpolicies 14 and not the association between data objects 32 and controlpolicies 14. The association between data objects and control policiesis stored only in the CPT 23 of the protected data objects 32. Thisdesign implies that the storage of the policy server 29 dedicated topolicies 14 scales in proportion to the number of control policies 14defined. The storage of the policy server is not affected by the numberof unique protected data objects 32. It is also not affected by thenumber of copies of these protected data objects.

The preferred embodiment of the present invention has the CPT 23 locatedin front of the data object 32 (i.e. the CPT is encountered before thedata object when scanning a protected data object 32 starting with thefirst byte of the protected data object). A different embodiment couldplace the CPT at the end or at any other explicit location within theprotected data object 32.

The preferred embodiment allows both the policy server 29 and the clientagent 26 of FIG. 6 to construct CPTs 23.

Reference Monitoring

FIG. 9 describes the logic followed by the reference monitor 24 of FIG.6 on an operation that accesses a protected data object 32. Given aparticular operation, the reference monitor 24 in step 61 firstdetermines if the operation accesses a protected data object 32. Thischeck involves looking for a CPT 23 on the data object. If no CPTexists, the reference monitor 24 allows the application 21 to continueat step 62. If a CPT 23 exists, the monitor 24 in step 63 checks theCPT's version field 51 and determines if the version of the CPT is thecurrent version. If it is not, the reference monitor proceeds to step64, which is explained in FIG. 14.

If the monitor 24 can interpret the CPT 23, the monitor in step 65proceeds to check the integrity of the CPT via field 59 (FIG. 8). If theCPT has been tampered with, the monitor 24 displays an error message instep 66; otherwise, in step 67 it uses the control policy id (field 54,FIG. 8) in the CPT along with the user's authentication credentials todetermine the user's usage rights for this protected data object 32.Given a set of usage rights, the monitor in step 68 determines if theuser is authorized to perform the requested operation. If not, themonitor 24 in step 69 inhibits the application 21 from performing therequested operation and displays an appropriate error message.

If the user appears in multiple roles under the corresponding(associated) control policy 14, the preferred embodiment aggregates theusage rights for each of the roles containing the user. This aggregationyields a set of usage rights that contains all of the positive rights ofthat user's individual roles. Clearly, another embodiment might use adifferent aggregation method.

If the operation is authorized, the monitor 24 in step 70 uses the KEKof the control policy 14 identified in the CPT to decrypt the CEK usedto encrypt and decrypt the contents of the subject protected data object32. The sections on CPT update and disaster recovery below describe someexceptional conditions that may occur during the processing of step 70in some embodiments.

Finally, given a decrypted CEK, the monitor 24 in step 72 uses the CEKto either decrypt the encrypted contents on a read operation or encryptnew contents on a write operation.

Architecture of Client Agent 26

FIG. 10 illustrates the details of the preferred embodiment of theclient architecture of the present invention. This embodiment splits theclient agent 26 of FIG. 6 into a client handler process 82 and anintegration bundle 84. There is one client handler process 82 per usermachine. The integration bundle 84 could be implemented as a singledynamically linked library that would be loaded into each processrunning on the user machine. The integration bundle 84 contains thereference monitor 83 and crypto engine 85 analogous to those 24, 25described in FIG. 6.

The client handler process 82 acts as a local proxy for the policyserver 29 of FIG. 6. The client handler process 82 contains a policyservice and cache 86 for caching and managing control policies 14received from the policy manager 27 of FIG. 6, and it contains a keyservice and cache 87 for securely caching and managing KEKs from the keymanager 28 of FIG. 6.

Under this embodiment, the reference monitor 83 requests the policy KEKfrom the key service and cache 87 in the client handler process 82 inorder to extract the CEK for a protected document from its CPT (step 70of FIG. 9). Once the CEK is obtained, the integration bundle 84 scrubsthe KEK from its memory and passes the CEK to the crypto engine 85.

The client handler process 82 also includes a logging service 88 forcollecting log information from each integration bundle 84 andeventually passing that log information back to the policy server 29 ofFIG. 6.

FIG. 11 describes the logic followed by the client handler process 82 ofFIG. 10. The handler sits in an event loop waiting for one of theseveral events labeled on the outgoing edges of step 90. When a new userlogs in and authenticates to the client machine, the client handlerprocess 82 will request all policies 14 on the policy server 29 relatedto the user, as stated in step 91. On a regular polling interval, thehandler process 82 in step 92 checks the policy server 29 for newpolicies 14 related to the logged-in user or changes to the cachedpolicies 14.

Some control policies 14 state how long they can be cached and usedoff-line. When such policies timeout, the handler process 82 in step 93will re-fetch expired policies 14 from the policy server 29. The controlpolicy KEK can also expire; the embodiment's handling of this time outcondition is described below in the section labeled “Expired KEKs andCPT Update.”

The preferred embodiment currently implements a three-way toggle(labeled Basic, Standard, and High) for setting control policy KEKexpiry periods and cache timeout values. The policy KEK validity periodand length of time before cached policy timeout are longer in the “Low”setting than the “Medium” setting, providing more potential exposure ifa KEK is compromised or a control policy changed. The “High” settingprovides the highest level of security and thus lowest level ofexposure; however, it also implies that users can work off-line forshorter periods of time. Each deployment of the embodiment of thepresent invention will select control policy KEK expiry periods andcache timeout values according to their level of risk tolerance and needfor off-line use of protected data objects 32.

Finally, the policy server 29 can prompt the handler processes 82 ofonline clients to flush and refresh their cached policies, as stated instep 94. Off-line clients will synchronize their cached policy storeswith the policy server 29 when again connected.

For steps 91-94, the client handler process 82 in step 95 will check tomake sure that the necessary network communication occurred. Ifeverything was successful, the handler process 82 in step 96 will cachethe received control policies 14 in secure storage. If the client had nonetwork connectivity with the policy server 29, the handler process 82in step 97 will record the missed event for replay later in steps 98 and99, after network connectivity is restored.

Expired KEKs and CPT Update

The CPT 23 of a protected data object 32 is the only structure in thepresent invention that contains the CEK used to encrypt the data object32. As explained earlier, the CEK is encrypted with the KEK of thecontrol policy 14 identified in the control policy id field 54 of FIG.8. To limit the risks associated with a compromised KEK, the systemlimits the lifetime of such encryption keys. This means however that aprotected data object 32 in the field may be no longer accessible onceits control policy KEK expires. Since the system does not have access toall data objects protected by a control policy 14 when the policy's KEKexpires, the system must have a mechanism for allowing access to dataobjects protected with an expired KEK and eventually lazily updating theCPT 23 of those data objects with the control policy's current KEK.

The policy server 29 of FIG. 6 is responsible for defining and managingthe lifetime of each control policy KEK.

The preferred embodiment of the present invention assigns a uniqueidentifier to each KEK within a control policy 14. Using key manager 28,the policy server 29 stores the current KEK and maintains a history ofKEKs for each active control policy 14. This history may contain allKEKs ever generated for a control policy 14, or it may contain only alimited number of the most recent expired KEKs for that policy.

To let the client agent 26 of FIG. 6 determine if it has the correct KEKfor decrypting the CEK of a protected data object 32, the encrypted CEKfields 56 and 57 of FIG. 8 include the (plaintext) value of the KEKunique identifier used to encrypt the CEK. To increase the probabilitythat the client of an authorized user has the KEK necessary to decryptthe CEK of a protected data object 32, the preferred embodiment of thepresent invention (e.g., policy server 29) distributes to the clientagent 26 not only the current KEK for a control policy 14 but also someportion of the most recent stored history of KEKs for the controlpolicy. The length of the distributed history is less than or equal tothe length of the history maintained on the policy server 29 by keymanager 28.

We will consider two cases associated with an attempt to access aprotected data object 32 with a CEK encrypted with an expired controlpolicy KEK; we consider further cases in the later section entitled“Disaster Recovery and CPT Version Control.” Both of the current casesassume that the policy server 29 maintains a complete history of expiredKEKs and distributes only a limited number of the most recently expiredkeys to the client agent 26. We assume that it is not practical for thepolicy server 29 to distribute a complete history of expired KEKs toevery client agent 26. FIG. 12 illustrates the scenario for anembodiment that distributes the current and past three expired KEKs 125to the client agent 26; the figure assumes that a KEK comprises a keypair 121 a,b.

In the first case, if the expired control policy KEK is one of the onessent by the server 29 in the distributed history, the client agent 26 isable to decrypt the CEK, use this CEK to access the protected dataobject 32, and create a new CPT for the protected data object 32 thatuses the control policy's current KEK. All of this occurs without anyinvolvement of the user or further communication with the policy server29, i.e. it could occur even while the client was off-line.

The second case solves the problem that the expired KEK is not part ofthe history distributed to the client agent 26. To recover from thissituation, the client agent 26 must be online and able to communicatewith the policy server 29, since the policy server maintains a completehistory expired KEKs for the control policy 14 of the protected dataobjects 32. The preferred embodiment simply has the client agent 26request the particular expired KEK of the control policy 14 of interest.When the policy server 29 responds with the appropriate archived KEK,the client proceeds as above (as if it found the expired KEK in thedistributed history).

FIG. 12 also illustrates that there may exist times when a controlpolicy 14 has no current KEK, due to the expiration of the current KEK.The preferred embodiment of the current invention generates a new KEKfor a policy only when a client agent 26 asks for the user-specificusage rules and current KEK of a control policy (step 91 of FIG. 11). Toguarantee that the client agent 26 does not have to wait an excessiveamount of time for step 91 of FIG. 11 to complete, the policy server 29does cache a set of pre-generated KEKs. This cache of KEKs is used tosatisfy demands for a new current KEK in response to a client agent's 26request for a control policy 14 without a current KEK. The cache ofpre-generated KEKs is managed using a simple low and high watermarkscheme well known to those practiced in the art. This approach in thepreferred embodiment guarantees that the policy server 29 does notgenerate a large number of unused KEKs that it would need to archive forcontrol policies 14 with protected data objects 32 that experience longperiods of inactivity.

Persistence Models for Protected Data Objects

The present invention supports two explicit persistence models forprotected data objects 32. In general, the protected data objects 32 ofa control policy 14 are either considered permanent or ephemeral assets.

In the “permanent” model, protected data objects 32 within a controlpolicy 14 are considered permanent assets that should be protected andnever lost. The preferred embodiment implements this model by encryptingthe CEK of each protected data object 32 with the public master KEK ofthe policy server 29. This encrypted value is stored in the one of theencrypted CEK fields (e.g., field 56 of FIG. 8); the other field (field57 of FIG. 8) contains the CEK encrypted with the current KEK of thecontrol policy identified in field 54 of FIG. 8.

The next section, entitled “Disaster Recovery and CPT Version Control”,describes how the preferred embodiment uses the private master KEK to bealways able to recover the CEK of a protected data object 32. For now,we simply state that the master KEK of the policy server 29 also has avalidity period, except that the validity period of the master KEK istypically longer than those assigned to control policy KEKs. Thevalidity period can be longer because, as explained in the next section,the private portion of the master KEK is never distributed to the clientagents 26 (i.e., it is used only on the policy server 29). Since themaster KEK has a validity period, the preferred embodiment alsoassociates a unique identifier with each generated master KEK of thepolicy server 29, and this identifier is stored with the encrypted CEKin field 56 of FIG. 8. Thus, contents stored in the storage for fields56 and 57 in FIG. 8 are identical.

In the “ephemeral” model, protected data objects 32 within a controlpolicy 14 are considered ephemeral assets that should be protected forsome pre-determined period of time and then destroyed. By “destroyed” wemean that it is theoretically impossible to recover the plaintext of theprotected data object 32.

The preferred embodiment implements the “ephemeral” model by encryptingthe CEK in the CPT 23 not with the policy server's master KEK but with a“policy master” KEK (field 56 of FIG. 8). The system never encrypts theCEK of the protected data object 32 with the server's master KEK. Thepolicy master KEK has all of the same attributes as the server masterKEK (e.g., it has a very long expiration time, never leaves the server29, and supports recovery of the CEK as long as it is archived).

When the owner of an ephemeral policy decides that it is time topermanently destroy all data objects associated with that policy 14, heor she simply requests that all archived copies of the policy masterKEKs for that policy be deleted on the policy server 29.

Disaster Recovery and CPT Version Control

There are many types of disasters that an embodiment of the presentinvention must protect against and recover from (e.g., loss of thepolicy store and restoration of that store from backups). In thissection, we focus on two unique aspects of the present invention'sdisaster recovery mechanisms. The first concerns embodiments thatmaintain only a limited history of control policy KEKs (or have throughsome catastrophic event lost all of the archived KEKs for one or morecontrol policies 14). The second describes support within the presentinvention for forward and backward compatibility of CPT formats. Thisfeature is again necessary to address the dynamic nature of theenterprise security space and to ensure that the system is always ableto recover the CEK stored in the CPT 23 of a protected data object 32that may not have been referenced for years.

FIG. 13 expands upon the logic followed by the reference monitor 24 ofFIG. 6 in step 70 of FIG. 9. At this point, the monitor 24 attempts toextract the CEK of the protected data object 32 from the CPT 23 (both ofFIG. 6). The client agent 26 already has the current KEK and some number(possibly zero) expired KEKs of the subject control policy 14. Themonitor 24 compares (step 110) the unique identifier of the current KEKwith the unique identifier (stored in field 57 of FIG. 8) of the KEKused to encrypt the CEK. If the identifiers match, the monitor 24proceeds with decryption of the encrypted CEK, as stated in step 115 ofFIG. 13.

As described above, the KEK for the control policy can expire; theembodiment identifies such an occurrence by noticing that none of theunique identifiers of the stored KEKs match the unique identifier of theKEK used to encrypt the CEK. To recover, in step 111, the monitor 24extracts the CPT 23 and sends it to the policy server 29 with a requestfor the server to encrypt the CEK with the current policy KEK. Theserver 29 in step 112 recovers the CEK by using the appropriate masterKEK (server or policy), as indicated by the unique identifier storedwith the encrypted CEK. The server 29 in step 113 returns the updatedCPT to client agent 26. The client agent 26 in step 114 retrieves theCEK from the received CPT, generates a new CEK, wraps it into an updatedCPT, and replaces the original CPT 23 if the protected data object 32 isnot marked read-only or stored on read-only media, and proceeds to step115 using the updated CPT. The client may cache the received CPT in thecase where the data object 32 is marked read-only.

The preferred embodiment treats the versioning of CPT formats as adisaster recovery problem. This approach allows the embodiment todistribute client agents 26 with code that only knows how to interpretthe current CPT format and how to recover from disasters.

FIG. 14 describes the logic followed by the reference monitor 24 of FIG.6 when it gets to step 64 of FIG. 9. The monitor 24 reaches this logicwhen the version of the CPT 23 of a protected data object 32 (both ofFIG. 6) does not match the CPT version supported by the monitor 24. Thereference monitor 24 in the client agent 26 in step 100 extracts theentire CPT from the protected data object 32. In step 101, the clientagent 26 sends the extracted CPT to the policy server 29 with a requestto convert the CPT to the specified version that the client agent 26supports. The server 29 in step 102 uses the version field 51 of the CPTto select the correct converter routine, which simply maps the fields inthe given version of the CPT data structure to the fields in thespecified version (possibly using a canonical intermediate form). Noticethat only the server 29 needs to have the entire set of converter codes.During this conversion, the server 29 in step 103 decrypts the CEK usingeither the indicated control policy KEK or the master KEK, andre-encrypts the CEK with the current control policy KEK and master KEK.The server 29 in step 104 returns the updated CPT to client agent 26.The client in step 105 extracts the current CEK, renews the CEK, updatesthe received CPT, caches the updated CPT, replaces the original CPT ifthe protected data object 32 is not marked read-only or stored onread-only media, and proceeds to step 65 of FIG. 9 using the updatedCPT.

Read-Only Protected Data Objects

So far, the description has generally assumed a collaborativeenvironment involving the creation and modification of protected dataobjects 32. The preferred embodiment also supports a publish-only modelof document generation and distribution. In particular, the preferredembodiment allows the business process administrator to indicate thatthe KEK for a control policy 14 should always remain valid. This optionis desirable when the administrator knows that the data objectsprotected by the control policy 14 are read-only or are stored onread-only computer media. Even though the system cannot update the CPT23 of a read-only data object 32, it may still want to expire thepolicies 14 associated with read-only documents in the client's policycache 86 to restrict the length of time allowed for off-line viewing ofread-only data objects.

Policy Identification and Data Object Transfer

FIG. 15 illustrates how the preferred embodiment displays the name forthe control policy 14 currently protecting the data object displayed ina computer window. The subject control policy name is displayed in adrop-down window object called the droplet control 120. When activated,the drop-down window displays the name, of the business process 122containing the active control policy 124, and the other businessprocesses 12 and control policies 14 that the user may transfer theprotected data object to.

In one embodiment, an ActiveX Window supports droplet control 120.Contents and hierarchy of same are obtained from policy server 29 viacache 86, tag 23 and/or client handler 82 as further explained below.

FIG. 16 describes the logic involved in transferring a data object(represented by a document) between control policies 14. Thetransferring of a protected data object 32 from one control policy 14 toanother is an important aspect of a dynamic, distributed, andcollaborative environment, as described earlier in reference to FIGS.2-5. In particular, the preferred embodiment allows business processowners (i.e. business administrators) to specify the flow of informationbetween control policies 14 within or between business processes 12. Thebusiness process owners define the flows while authorized users performthe actual transferring of protected data objects. Often a transfer willoccur as part of normal workflow.

An authorized user in step 130 opens a document in arights-management-aware application 21. This might be a new document 22(data object), in which case the client agent 26 in step 132 displaysthe default “Unmanaged” control policy in droplet control 120.Alternatively, this might be an existing protected document, in whichcase the agent 26 in step 132 displays the name of the control policyprotecting the document 22 in the droplet control 120. The user in step134 edits and further manipulates open document within the usage rightsspecified by the control policy 14 for that user. The logic flow fromstep 134 back to itself represents the fact that such editing maycontinue for some unspecified and extended period of time.

At some point, the user in step 136 may decide to activate the dropletcontrol 120 and select a new control policy 14 to which he would like totransfer the protected document. After selection, the agent 26 in step138 creates a new CPT 23 with the selected control policy identifier init and tags the document 22 with it. If specified in the control policy14, an authorized user may in step 136 select the “Unmanaged” controlpolicy, in which case the agent 26 in step 138 does not create a newCPT, deletes the existing CPT, and decrypts the document 22. After step138, the user can continue to edit the document 22 under the constraintsof the new control policy 14.

Each control policy 14 in the system records a list of users with theauthority to transfer data objects 22 out of the protection provided bythat control policy. The control policy 14 also contains a list of userswith the authority to assign new data objects 22 to the control policy.In order for a user to transfer a data object 22 from its currentcontrol policy 14 to a new control policy, the user must be a member ofthe “transfer-out” list of the current control policy 14 and a member ofthe “assign-to” list of the new control policy 14.

“Transfer” rights are not necessary, i.e. the “transfer-out” and“assign-to” lists of a control policy 14 can be empty. However, in thepreferred embodiment of the present invention, at least one of the rolesin a control policy 14 will allow users to assign data objects 22 to thepolicy 14. If none of the roles has assign privileges, the policy 14would not have any meaning (i.e., it would never have objects associatedwith it). The “assign-to” list may become empty because the privilegewas needed only initially to assign data objects to the control policy14. For instance, a member may have “assign-to” privileges during theinitial creation of the policy and assignment of data objects to thepolicy. After this initialization, the “assign-to” privilege is removedand the policy 14 controls a fixed set of objects.

In general, the preferred embodiment supports three kinds of “transfers”within the hierarchy of business processes 12 (FIG. 1):

-   (a) An authorized user may be granted the privilege of changing the    association between a data object 22 and its control policy 14    within a single business process 12.-   (b) A user may also be granted the privilege of moving data objects    22 between business processes 12.-   (c) A user may also be granted the privilege of moving data objects    22 out of the rights management system, i.e. the data object 22    resulting from the transfer is no longer managed or protected.

The types of transfers described above can be explicitly initiated by anauthorized user through the droplet control 120 described earlier, ortransfers can be implicitly initiated as a byproduct of some otherelectronic action undertaken by the authorized user. We refer to thislatter category as “automatic transfers.”

The policy 14 associated with a data object 22 may be changedautomatically via merge operations (e.g., cut/paste operations). Thepreferred embodiment of the present invention implements the followingkinds of automatic transfers on merge operations: If a protected dataobject 32 is pasted into an unmanaged data object, the targeted dataobject assumes the policy 14 of the pasted object. If the protected dataobject is pasted into a protected data object with a different policy14, the target object maintains its policy and the paste is allowed tocomplete only if the source data object's policy allows transfer and thetarget data object's policy allows assign.

The preferred embodiment of the present invention implements “automatictransfers” by integrating a standalone transfer tool into a softwarecomponent of an existing electronic business process. For example, areport generator for a large database system might be modified to usethe standalone transfer tool to produce reports as protected dataobjects 32 under a pre-configured control policy 14. As another example,an email server might be configured to use the standalone transfer toolas a type of filter (i.e. exploiting those interfaces used by anti-virusfilters) to transfer automatically data objects from one control policy14 to another based on the people or groups in the “to” and “from”fields of an email message. An automatic transfer would take place onlyif the sender of the email message had the appropriate transfer rights.Such an embodiment would also want to employ digital signatures toensure that the email message actually came from the person specified inthe “from” field.

Off-Line Collaboration

Collaboration in a dynamic and distributed environment implies that theonly authoritative copy of a protected data object 32 may reside in thefield, away from the policy server 29, and in locations not accessibleby the business process owner. A system in support of dynamic,distributed, and collaborate environments must make it easy for two (ormore) authorized users to generate and share protected data objects 32both on and off-line. The preferred embodiment of the present inventionsupports such a goal with the only criterion that the authorized usersmust have had some recent access to the policy server 29, where “recent”means within the cache timeout for the control policy 14 under whichthey wish to collaborate. In other words, collaboration is driven bypre-defined business processes 12 and not by pre-registered data objects32.

FIG. 17 presents a flow diagram illustrating collaboration between twousers within a rights management system 200 based on the presentinvention, where the collaboration occurs through a document (dataobject 22) that was never known to the policy server 29. Step 140 beginswith an administrator creating a control policy P that includes bothusers A and B in roles. Users A and B in step 141 are logged in to theirlaptops connected to the corporate network where the policy server 29 islocated. In step 142, the client handler processes 82 on the users'laptops cache the control policy P and its KEK. Users of A and B in step143 then disconnect from the corporate network and take their laptops toan off-site meeting. At this point, the client handler processes 82 areprepared to permit any collaborative activity within the bounds of thecached control policies 14; the client handler processes 82 act astrusted agents of the rights management system 200.

While off-line, user A in step 144 creates a sensitive data object D (inthe example, a document) and protects it with control policy P. Thisaction takes place while user A is disconnected from the policy server29. Since control policy P is cached on user A's laptop, he or she isable to create and protect document D. User A in step 145 gives a copyof document D to user B. User B in step 146 is able to edit protecteddocument D on his or her laptop while also disconnected from the policyserver 29. The collaboration of users A and B around document D (or anyother document protected by control policy P) continues in step 147, aslong as no expiry periods occur.

Audits, Forensics, and Compliance

The preferred embodiment of the present invention supports logging ofthe activities (granted and denied) monitored and controlled by theclient agent 26 of FIG. 6. The logging service 88 in FIG. 10 collectsthe log data from the individual rights-management-aware applications 21and communicates the data back to the policy server 29. The collectedinformation can then be reviewed and mined by the business process ownerto support business needs, such as audits, forensics, and compliance.

Auditing the activities associated with the data objects 32 of abusiness process 12 does not necessarily require encryption of theidentified data objects 32. In one embodiment of the invention, theidentified data objects 32 may be simply “managed” and not “protected.”In other words, auditing requires only that an identified data object 32have a CPT 23; it does not require that the contents 22 of that dataobject 32 be encrypted.

The object id field 55 in the CPT 23 (FIG. 8) aids in audits, forensics,and compliance. It is a globally unique identifier generated when theclient agent 26 first creates a protected data object 32. If the newdata object 22 was generated from an existing protected data object(e.g., via a “Save As” command), a log record is written linking the newand existing data objects using their object identifier 55 values.Otherwise, the system 200 records that the new protected data object 32was generated from scratch or from an unmanaged data object 22.

This example emphasizes the fact that the preferred embodiment of thepresent invention uses object identifiers only for audits, forensics,and compliance purposes. The embodiment does not use the objectidentifier 55 of a protected data object 32 for determining the controlpolicy 14 or associated usage rules.

While this invention has been particularly shown and described withreferences to preferred embodiments thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the scope of the inventionencompassed by the appended claims.

1. A computer method of protecting data objects, said method comprisingthe steps of: encrypting a data object with a content encryption key;and encrypting the content encryption key with a key encryption key of acontrol policy associated with the data object.
 2. The method ofprotecting data objects of claim 1, further comprising: recording acontrol policy tag corresponding to the data object.
 3. The method ofprotecting data objects of claim 2, further comprising: storing theencrypted content encryption key in the control policy tag.
 4. Themethod of protecting data objects of claim 3, further comprising:decrypting the content encryption key stored in the control policy tagwith a cached key encryption key; and decrypting the data object withthe decrypted content encryption key.
 5. The method of protecting dataobjects of claim 2, wherein the control policy tag is attached to thedata object.
 6. The method of protecting data objects of claim 2,wherein the data object is read-only.
 7. The method of protecting dataobjects of claim 2, wherein the control policy tag is constructed on acontrol policy server.
 8. The method of protecting data objects of claim2, wherein the control policy tag is constructed on a client.
 9. Themethod of protecting data objects of claim 2, wherein the key encryptionkey of a control policy has an associated validity period.
 10. Themethod of protecting data objects of claim 9, further comprising:automatically replacing an expired key encryption key of a controlpolicy.
 11. The method of protecting data objects of claim 10, whereinautomatically replacing an expired key encryption key of a controlpolicy further comprises: selecting a proper key from a set ofdecryption keys comprising at least one of: a next future key, a currentkey, a recently expired key, and an old key received from a controlpolicy server.
 12. The method of protecting data objects of claim 2,further comprising: storing a second copy of the content key encryptedwith a second encryption key in the control policy tag.
 13. The methodof protecting data objects claim 12, wherein the second encryption keyis a control policy server key encryption key.
 14. The method ofprotecting data objects of claim 12, further comprising: providingaccess to a data object with an expired key encryption key of thecontrol policy using the control policy server key encryption key. 15.The method of protecting data objects of claim 2, further comprising:protecting integrity of the control policy tag against tampering. 16.The method of protecting data objects of claim 15, wherein the step ofprotecting the integrity of the control policy tag against tamperingfurther comprises using a secure hash over control policy tag fields.17. The method of protecting data objects of claim 2, furthercomprising: checking a control policy server for modifications to thecontrol policy associated with the data object.
 18. The method ofprotecting data objects of claim 17 wherein the control policy tagcomprises a uniform resource locator of a control policy server and acontrol policy locator.
 19. The method of protecting data objects ofclaim 17, further comprising: revoking a user's access to the dataobject upon detection of the changes to the control policy that preventthat user from further access to the data object.
 20. The method ofprotecting data objects of claim 1, further comprising the step of:storing the key encryption key of the control policy on a control policyserver.
 21. The method of protecting data objects of claim 20, whereinthe control policy comprises at least an indication of a set of userswho may access the data object, an indication of privileges granted toeach user of the set, and an indication of a set of users who may defineor edit the control policy, the method further comprising the steps of:retrieving a decryption key for the key encryption key of the controlpolicy and the indication of privileges for a user by the user if theuser is indicated in the control policy to be in a set of users who mayaccess the data object.
 22. The method of protecting data objects ofclaim 21, wherein retrieving the key encryption key of a control policyfurther comprises determining if a user is authenticated.
 23. The methodof protecting data objects of claim 21, further comprising: storing anindication of a duration of time for which the user may access the dataobject; and revoking a user's access to the data object upon expirationof the duration of time.
 24. The method of protecting data objects ofclaim 23, further comprising: decrypting the data object; and allowingthe user to access the data object.
 25. The method of protecting dataobjects of claim 23, further comprising: destroying the key encryptionkey of the control policy upon expiration of the duration of time. 26.The method of protecting data objects of claim 1 further comprising:changing the content encryption key whenever the data object ismodified.
 27. The method of protecting data objects of claim 2 furthercomprising: automatically replacing an expired control policy tag. 28.The method of protecting data objects of claim 27, wherein the controlpolicy tag comprises at least one of: a length field and a versionfield.
 29. The method of protecting data objects of claim 28, whereinreplacing the expired control policy tag further comprises: sending thecontrol policy tag to a control policy server if a control policyversion does not match a current version.